Optimal data storage configuration in a blockchain

ABSTRACT

A blockchain of transactions may be referenced for various purposes and may be later accessed by interested parties for ledger verification and information retrieval. One example method of operation may include assigning one blockchain block to one group member node among a group of blockchain nodes, storing the one blockchain block in the one group member node, assigning a verification of the one blockchain block to one or more verification blockchain nodes which are part of the group of blockchain nodes, and storing the verification of the one blockchain block in each of the one or more verification blockchain nodes.

TECHNICAL FIELD

This application generally relates to managing of transaction datastorage in a ledger, and more particularly, to optimal data storageconfiguration in a blockchain.

BACKGROUND

The blockchain may be used as a public ledger to store any type ofinformation. Although, primarily used for financial transactions, theblockchain can store any type of information including assets (i.e.,products, packages, services, status, etc.). The blockchain may be usedto securely store any type of information in its immutable ledger.Decentralized consensus is different from the traditional centralizedconsensus, such as when one central database used to rule transactionvalidity. A decentralized scheme transfers authority and trusts to adecentralized network and enables its nodes to continuously andsequentially record their transactions on a public “block,” creating aunique “chain” referred to as the blockchain. Cryptography, via hashcodes, is used to secure the authentication of the transaction sourceand removes the need for a central intermediary.

Blockchain's policy is to save all the block data on each of the nodesof the blockchain to ensure data consistency. Based on this policy, eachnode's maximize space for data utilization is limited and each node isrequired to store a large amount of data. In traditional blockchains,each node stores information for all of the blocks. With moretransactions/blocks, tremendous storage is consumed on each node.

SUMMARY

One example embodiment may include a method of operation that mayinclude one or more of assigning one blockchain block to one groupmember node among a group of blockchain nodes, storing the oneblockchain block in the one group member node, assigning verification ofthe one or more blockchain data block to one or more verificationblockchain nodes which are also part of the group of blockchain nodes,and storing the verification of the blockchain data block in each of theone or more verification blockchain nodes.

Another example embodiment may include an apparatus that includes aprocessor configured to perform one or more of assign one blockchainblock to one group member node among a group of blockchain nodes, storethe one blockchain block in the one group member node, assign averification of the one blockchain block to one or more verificationblockchain nodes which are also part of the group of blockchain nodes,and store the verification of the one blockchain block in each of theone or more verification blockchain nodes.

Still another example embodiment may include a non-transitory computerreadable storage medium configured to store instructions that whenexecuted cause a processor to perform one or more of assigning oneblockchain block to one group member node among a group of blockchainnodes, storing the one blockchain block in the one group member node,assigning verification of the one or more blockchain data block to oneor more verification blockchain nodes which are also part of the groupof blockchain nodes, and storing the verification of the blockchain datablock in each of the one or more verification blockchain nodes.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 illustrates a node/block assignment configuration according toexample embodiments.

FIG. 2 illustrates a block group assignment configuration according toexample embodiments.

FIG. 3 illustrates a node group setup configuration according to exampleembodiments.

FIG. 4 illustrates a system signaling diagram of the interactionsbetween new transactions, certain member nodes and a blockchainaccording to example embodiments.

FIG. 5A illustrates a flow diagram of an example of a storageconfiguration in a blockchain according to example embodiments.

FIG. 5B illustrates another flow diagram of an example of storageconfiguration in a blockchain according to example embodiments.

FIG. 6 illustrates an example network entity configured to support oneor more of the example embodiments.

DETAILED DESCRIPTION

It will be readily understood that the instant components, as generallydescribed and illustrated in the figures herein, may be arranged anddesigned in a wide variety of different configurations. Thus, thefollowing detailed description of the embodiments of at least one of amethod, apparatus, non-transitory computer readable medium and system,as represented in the attached figures, is not intended to limit thescope of the application as claimed, but is merely representative ofselected embodiments.

The instant features, structures, or characteristics as describedthroughout this specification may be combined in any suitable manner inone or more embodiments. For example, the usage of the phrases “exampleembodiments”, “some embodiments”, or other similar language, throughoutthis specification refers to the fact that a particular feature,structure, or characteristic described in connection with the embodimentmay be included in at least one embodiment. Thus, appearances of thephrases “example embodiments”, “in some embodiments”, “in otherembodiments”, or other similar language, throughout this specificationdo not necessarily all refer to the same group of embodiments, and thedescribed features, structures, or characteristics may be combined inany suitable manner in one or more embodiments.

In addition, while the term “message” may have been used in thedescription of embodiments, the application may be applied to many typesof network data, such as, packet, frame, datagram, etc. The term“message” also includes packet, frame, datagram, and any equivalentsthereof. Furthermore, while certain types of messages and signaling maybe depicted in exemplary embodiments they are not limited to a certaintype of message, and the application is not limited to a certain type ofsignaling.

The instant application in one embodiment relates to managing oftransaction data storage in a trust ledger, and in another embodimentrelates to distributing the transaction data across multiple nodes inthe blockchain in an optimal distributed data configuration.

Example embodiments provide configurations to store blockchain datafragmentally among peer nodes of the blockchain instead of saving a fullcopy on each node. In one example, each block of the blockchain willhave more than one copy stored on more than one node for redundancy,however, not all nodes will have all blocks. Also, a group is createdfor certain data blocks with additional verification blocks based on arule, such as a linear equation. Both verification blocks and datablocks are stored randomly to assure data security.

Block data can be classified as two types, one is the original datablock which is stored in block nodes (‘B’ nodes), the other is theverification block which is stored in verification nodes (‘V’ nodes). Ina group, an integer ‘N’ is defined as the number of data block nodes(‘B’ nodes) in a group each having more than one node. M represents thenumber of verification nodes (‘V’ nodes) in a group. The total nodes ‘S’is divided by (N+M), so the group count is S/(N+M). For a group ‘B’node, each blockchain ‘B’ node in one group will store data blocks. Fora group ‘V’ node, each block chain ‘V’ node in one group will store achecksum for all ‘B’ nodes in a same group. The number of group V nodesdepends on a data integrity/restore requirement level. By using linearencoding, the ‘N’ original block data generates ‘M’ verification blocks.The blocks B1, B2, . . . Bn are each assigned to one node in a group.The verification nodes V1, V2 . . . VM store the verification block datacomputed by linear encoding of the blocks.

FIG. 1 illustrates a node/block assignment configuration according toexample embodiments. Referring to FIG. 1, the configuration 100 includesvarious nodes indicated by the circles as ‘B’ nodes 112 and thetriangles as ‘V’ nodes 114. The group example 150 includes a set of ‘B’nodes and ‘V’ nodes. The blocks 132, 134 and 136 represent individualblocks which must be assigned to the blocks of each group. All nodes (S)are distributed into different groups and each group contains N blocknodes and M verification nodes. The nodes' distribution is not fixed andis preferably is redistributed each cycle. In a cycle, each of the Nblock nodes has a single block data, and each of M verification nodeshas a single verification data as well. For each group, after N blockdata is recorded into the N ‘B’ nodes, the current cycle ends and a nextcycle begins. A group contains N block nodes (B nodes) and Mverification nodes (V node).

All the nodes are distributed into different groups, but due to securityconsiderations, this grouping is not fixed. As such, the nodes would bere-grouped after the current cycle ends. In a cycle, each of N datablock nodes could have only one block data, after each of N consecutiveblocks are individually distributed into one of N block nodes. In turn,each of all the N block nodes has 1 data block, and the nodes arere-grouped. Same as block nodes, each of the verification nodes also hasone verification block in a cycle, and is also re-grouped after a cycle.In addition, a node may act as a block node in a cycle, which also couldbe a verification node in another cycle. Since a node is notconsistently fixed in a same group, this assignment would advance asecurity level. Since each group contains (N+M) nodes (N block nodes andM verification nodes), for a total of ‘S’ nodes, then there would beS/(N+M) groups identified by the vertical rectangle 140. The first nodesin each group are all assigned block 1 (B1), these 2nd nodes in eachgroup are assigned block 2 (B2) and the Nth nodes are identified byblock N.

A linear encoder may be used to provide an N×M metric to multiply the Nblock data {B1, B2 . . . Bn}, where each of the blocks B are representedas a column vector. Also, an M verification block data may be generated{V1, V2, . . . Vm}. In the event that any of the M+N block data aremissing or corrupted, the missing data could be retrieved from theremaining block data by using linear decoding including original andverification block data. In a cycle block nodes are used to write a realdata block and verification nodes are used for verification purposes.Besides data in B nodes, verification in V nodes is also written as ablock. The data in B nodes can be seen as the real data. Verificationblocks in V nodes are the calculated blocks derived from data blocks.

FIG. 2 illustrates a block group assignment configuration according toexample embodiments. Referring to FIG. 2, the configuration 200 includesa cycle which contains N consecutive blocks. Prior to each cycle, all ofthe (S) nodes are randomly placed into a S/(N+M) group. Within eachgroup, each block is only written into one node. Same block data iswritten into nodes with same positions across other groups. For example,in a cycle, nodes from ‘1’ 212 to N+M are assigned to group ‘1’, nodesfrom N+M+1 214 to 2N+2M are assigned to group ‘2’, etc. Node ‘1’ andN+M+1 214 have the same block ‘1’ data, and node ‘2’ and N+M+2 have thesame block ‘2’ data. The verification nodes store verificationscorresponding to the blocks of the ‘B’ nodes in a same group. Forexample, verification nodes N+1 232 and 2N+M+1 234 correspond to similarnodes of the verification in the respective node groups. However, thisrandom grouping assignment procedure is not fixed and could vary in anext cycle.

FIG. 3 illustrates a block setup configuration according to exampleembodiments. Within a cycle, the M+N blocks are individually distributedin M+N nodes. Besides the original hash for the raw block data, threeadditional data fields may be added including a flag to denote the blockis a data or verification block, a prior node IP address, and/or a hashof all the above data (e.g., original block data, prior node IP address,flag, etc.). Referring to FIG. 3, the example block configurations 300include examples of data for each block 310, 320, and 330. Included inthis approach to storing blockchain block data, a previous node IPaddresses 312, 314 and 316 are assigned to a next node along with a hashof the previous data 322, 324 and 326. The block 1 header 332 and thehash of the previous block header 342 are part of the current block 310.Similarly, the next blocks 320 and 330 store the block 2 and 3 headers334 and 336, and the hashes of the previous blocks 344 and 346. Eachblock also has its own Merkle root 345, 347 and 349 and blocktransactions 350, 360 and 370. In a blockchain with S data blocks, forexample, if every N data blocks has M verification blocks, compared totraditional blockchain, the storage saving percent approaches theexpression (S−S/N)/S.

The blocks 310, 320 and 330 are the whole structures of data blocks. Ablock would include a flag used to denote this block is a data block orverification block, a prior node IP address (e.g. for a cycle), forexample, the block in the 3rd node has the 2nd node's IP in a group, andthe block in the 2nd node has the 1st node IP, and the 1st block storesthe last node's IP of a previous cycle, and a hash of the prior block inthe prior node (e.g. for a cycle), for example, the block in the 3rdnode has the hashed value of the 2nd block in the 2nd node in a samegroup. Also, the block in the first node would have the hashed value ofthe last block data in a previous cycle that could be searched by itsprior node IP address. Further, the block would have the originaltraditional block data for B nodes. For V nodes, this part is thecalculated verification data.

FIG. 4 illustrates a system signaling diagram of the interactionsbetween new transactions, certain member nodes and a blockchainaccording to example embodiments. Referring to FIG. 4, the systemconfiguration 400 includes transactions 410 being processed by theblockchain 430 to create blocks and assign group member nodes 420. Inthis example, when new blockchain transactions 412 are received, the newblocks are created, in turn, 414 and are assigned 416 to certain ones ofthe blockchain nodes to be stored at those selected group nodes 418. Oneexample may include 10 groups of N nodes, where the block #1 is assignedto node #1 of each of the 10 groups and no other nodes from the group ofN nodes. The blockchain 430 may be part of a system or virtual computerthat manages assignment of blocks to members. The verification node isassigned 422 as part of the group to store the verification informationfor each block 424. Other data included may include a prior node IPaddress of a previous node 426. The data may be hashed and assigned aflag along with prior address information to include in the block data428. Each of the elements 410, 420, 430 may be a device comprising aprocessor and memory or may be functionality performed by a device thatcomprises a processor and memory.

FIG. 5A illustrates a flow diagram 500 of an example of a storageconfiguration in a blockchain according to example embodiments. One ormore of the following may occur: assigning one blockchain block to onegroup member node among a group of blockchain nodes 512, storing the oneblockchain block in the one group member node 514, assigning averification of the one blockchain block to one or more verificationblockchain nodes which are also part of the group of blockchain nodes516, and storing the verification of the one blockchain block in each ofthe one or more verification blockchain nodes 518. The one blockchainblock may include original blockchain transaction data. The verificationincludes a checksum of the original blockchain transaction data. In thisexample, the one block is assigned to a plurality of different groupmembers each assigned to a respective plurality of different groups,wherein none of the plurality of different group members are members ofthe same group. The plurality of different group members each have asame respective assigned position within the respective plurality ofdifferent groups. The method may also include assigning a flag to eachof the block nodes and the verification nodes, such that the flag forthe block nodes is different from the flag for the verification nodes.The method may also include assigning a prior node IP address to each ofthe block nodes and the verification nodes, and hashing the priorblockchain block, a flag assigned to a prior node and the prior node IPaddress.

FIG. 5B illustrates another flow diagram 550 of an example of a storageconfiguration in a blockchain according to example embodiments. One ormore of the following may occur: identifying a plurality of groups ofblockchain nodes each of which are members of their respective groups552, identifying one or more potential blockchain transactions 554,assigning a first of the one or more potential blockchain transactionsto a member of a first group and at least one additional member of atleast one additional group among the plurality of groups 556, andperforming verification of the first potential blockchain transactionvia the member of the first group and the at least one additional memberof the at least one additional group 558, and then storing theverification of the one blockchain block 562. In this example, once thegroups are established, the members may also be assigned to verifytransactions in a manner that provides verification from one member of aparticular group and another member of at least one additional group.The groups may be created to include members which are not in the samelocation and unbiased and thus may provide proper authentication andauthorization of blockchain transactions prior to commitment to theblockchain.

The above embodiments may be implemented in hardware, in a computerprogram executed by a processor, in firmware, or in a combination of theabove. A computer program may be embodied on a computer readable medium,such as a storage medium. For example, a computer program may reside inrandom access memory (“RAM”), flash memory, read-only memory (“ROM”),erasable programmable read-only memory (“EPROM”), electrically erasableprogrammable read-only memory (“EEPROM”), registers, hard disk, aremovable disk, a compact disk read-only memory (“CD-ROM”), or any otherform of storage medium known in the art.

An exemplary storage medium may be coupled to the processor such thatthe processor may read information from, and write information to, thestorage medium. In the alternative, the storage medium may be integralto the processor. The processor and the storage medium may reside in anapplication specific integrated circuit (“ASIC”). In the alternative,the processor and the storage medium may reside as discrete components.For example, FIG. 6 illustrates an example network element 600, whichmay represent or be integrated in any of the above-described components,etc.

As illustrated in FIG. 6, a memory 610 and a processor 620 may bediscrete components of a network entity 600 that are used to execute anapplication or set of operations as described herein. The applicationmay be coded in software in a computer language understood by theprocessor 620, and stored in a computer readable medium, such as, amemory 610. The computer readable medium may be a non-transitorycomputer readable medium that includes tangible hardware components,such as memory, that can store software. Furthermore, a software module630 may be another discrete entity that is part of the network entity600, and which contains software instructions that may be executed bythe processor 620 to effectuate one or more of the functions describedherein. In addition to the above noted components of the network entity600, the network entity 600 may also have a transmitter and receiverpair configured to receive and transmit communication signals (notshown).

Although an exemplary embodiment of at least one of a system, method,and non-transitory computer readable medium has been illustrated in theaccompanied drawings and described in the foregoing detaileddescription, it will be understood that the application is not limitedto the embodiments disclosed, but is capable of numerous rearrangements,modifications, and substitutions as set forth and defined by thefollowing claims. For example, the capabilities of the system of thevarious figures can be performed by one or more of the modules orcomponents described herein or in a distributed architecture and mayinclude a transmitter, receiver or pair of both. For example, all orpart of the functionality performed by the individual modules, may beperformed by one or more of these modules. Further, the functionalitydescribed herein may be performed at various times and in relation tovarious events, internal or external to the modules or components. Also,the information sent between various modules can be sent between themodules via at least one of: a data network, the Internet, a voicenetwork, an Internet Protocol network, a wireless device, a wired deviceand/or via plurality of protocols. Also, the messages sent or receivedby any of the modules may be sent or received directly and/or via one ormore of the other modules.

One skilled in the art will appreciate that a “system” could be embodiedas a personal computer, a server, a console, a personal digitalassistant (PDA), a cell phone, a tablet computing device, a smartphoneor any other suitable computing device, or combination of devices.Presenting the above-described functions as being performed by a“system” is not intended to limit the scope of the present applicationin any way, but is intended to provide one example of many embodiments.Indeed, methods, systems and apparatuses disclosed herein may beimplemented in localized and distributed forms consistent with computingtechnology.

It should be noted that some of the system features described in thisspecification have been presented as modules, in order to moreparticularly emphasize their implementation independence. For example, amodule may be implemented as a hardware circuit comprising custom verylarge scale integration (VLSI) circuits or gate arrays, off-the-shelfsemiconductors such as logic chips, transistors, or other discretecomponents. A module may also be implemented in programmable hardwaredevices such as field programmable gate arrays, programmable arraylogic, programmable logic devices, graphics processing units, or thelike.

A module may also be at least partially implemented in software forexecution by various types of processors. An identified unit ofexecutable code may, for instance, comprise one or more physical orlogical blocks of computer instructions that may, for instance, beorganized as an object, procedure, or function. Nevertheless, theexecutables of an identified module need not be physically locatedtogether, but may comprise disparate instructions stored in differentlocations which, when joined logically together, comprise the module andachieve the stated purpose for the module. Further, modules may bestored on a computer-readable medium, which may be, for instance, a harddisk drive, flash device, random access memory (RAM), tape, or any othersuch medium used to store data.

Indeed, a module of executable code could be a single instruction, ormany instructions, and may even be distributed over several differentcode segments, among different programs, and across several memorydevices. Similarly, operational data may be identified and illustratedherein within modules, and may be embodied in any suitable form andorganized within any suitable type of data structure. The operationaldata may be collected as a single data set, or may be distributed overdifferent locations including over different storage devices, and mayexist, at least partially, merely as electronic signals on a system ornetwork.

It will be readily understood that the components of the application, asgenerally described and illustrated in the figures herein, may bearranged and designed in a wide variety of different configurations.Thus, the detailed description of the embodiments is not intended tolimit the scope of the application as claimed, but is merelyrepresentative of selected embodiments of the application.

One having ordinary skill in the art will readily understand that theabove may be practiced with steps in a different order, and/or withhardware elements in configurations that are different than those whichare disclosed. Therefore, although the application has been describedbased upon these preferred embodiments, it would be apparent to those ofskill in the art that certain modifications, variations, and alternativeconstructions would be apparent.

While preferred embodiments of the present application have beendescribed, it is to be understood that the embodiments described areillustrative only and the scope of the application is to be definedsolely by the appended claims when considered with a full range ofequivalents and modifications (e.g., protocols, hardware devices,software platforms etc.) thereto.

What is claimed is:
 1. A method, comprising: assigning one blockchainblock to a group member node and assigning a verification of the oneblockchain block to one or more verification blockchain nodes which arepart of one or more non-assigned group member nodes; and storing theverification of the one blockchain block in each of the one or moreverification blockchain nodes.
 2. The method of claim 1, wherein the oneblockchain block comprise original blockchain transaction data.
 3. Themethod of claim 1, wherein the verification comprises a checksum oforiginal blockchain transaction data.
 4. The method of claim 1, furthercomprising: assigning the one block to a plurality of different groupmembers each assigned to a respective plurality of different groups,wherein none of the plurality of different group members are members ofthe same group.
 5. The method of claim 4, wherein the plurality ofdifferent group members each have a same respective assigned positionwithin the respective plurality of different groups.
 6. The method ofclaim 1, further comprising: assigning a flag to each of the blockchainnodes and the verification blockchain nodes, wherein the flag for theblockchain nodes is different from the flag for the verificationblockchain nodes.
 7. The method of claim 6, further comprising:assigning a prior node IP address to each of the blockchain nodes andthe verification blockchain nodes; and hashing blockchain data of theblockchain block, a flag assigned to a prior node and the prior node IPaddress.
 8. An apparatus, comprising: a processor configured to: assignone blockchain block to a group member node and assign a verification ofthe one blockchain block to one or more verification blockchain nodeswhich are part of one or more non-assigned group member nodes; and storethe verification of the one blockchain block in each of the one or moreverification blockchain nodes.
 9. The apparatus of claim 8, wherein theone blockchain block comprises original blockchain transaction data. 10.The apparatus of claim 8, wherein the verification comprises a checksumof original blockchain transaction data.
 11. The apparatus of claim 8,wherein the processor is further configured to: assign the one block toa plurality of different group members each assigned to a respectiveplurality of different groups, wherein none of the plurality ofdifferent group members are members of the same group.
 12. The apparatusof claim 11, wherein the plurality of different group members each havea same respective assigned position within the respective plurality ofdifferent groups.
 13. The apparatus of claim 8, wherein the processor isfurther configured to: assign a flag to each of the blockchain nodes andthe verification blockchain nodes, wherein the flag for the blockchainnodes is different from the flag for the verification blockchain nodes.14. The apparatus of claim 13, wherein the processor is furtherconfigured to: assign a prior node IP address to each of the blockchainnodes and the verification blockchain nodes; and hash blockchain data ofthe blockchain block, a flag assigned to a prior node and the prior nodeIP address.
 15. A non-transitory computer readable storage mediumconfigured to store instructions that when executed cause a processor toperform: assigning one blockchain block to a group member node andassigning a verification of the one blockchain block to one or moreverification blockchain nodes which are part of one or more non-assignedgroup member nodes; and storing the verification of the one blockchainblock in each of the one or more verification blockchain nodes.
 16. Thenon-transitory computer readable storage medium of claim 15, wherein theone blockchain block comprise original blockchain transaction data. 17.The non-transitory computer readable storage medium of claim 15, whereinthe verification comprises a checksum of original blockchain transactiondata.
 18. The non-transitory computer readable storage medium of claim15, wherein the processor is further configured to perform: assigningthe one block to a plurality of different group members each assigned toa respective plurality of different groups, wherein none of theplurality of different group members are members of the same group. 19.The non-transitory computer readable storage medium of claim 18, whereinthe plurality of different group members each have a same respectiveassigned position within the respective plurality of different groups.20. The non-transitory computer readable storage medium of claim 15,wherein the processor is further configured to perform: assigning a flagto each of the blockchain nodes and the verification blockchain nodes,wherein the flag for the blockchain nodes is different from the flag forthe verification blockchain nodes; assigning a prior node IP address toeach of the blockchain nodes and the verification blockchain nodes; andhashing blockchain data of the blockchain block, a flag assigned to aprior node and the prior node IP address.